The creation of Java graphics user interfaces (GUIs) (Java is a registered trademark of Sun®) that support a Multi-Modal Workstation (MMW), UNIX workstation or Personal Computer (PC), (all generally referenced herein as a MMW) having one or more monitors, is currently implemented with the Java Swing package. When Java was originally created, only the Abstract Windows Toolkit (AWT) library was available for working with graphics. This package contains a simple set of classes such as Buttons, TextField, Label and others. A more advanced set of classes is contained in the later introduced library called Swing. Swing, like AWT, is a package that also includes buttons, text fields, and other classes for providing window controls. Swing allows GUIs to be built using the Java Software Development Kit (SDK). The names of the Swing components start with the letter J, for example, JButton, JTextField, JLabel, and so on. A graphics user interface GUI produced using Java Swing can have a “look and feel” which is either that of a Java platform, the native platform, or a particular specified platform. For instance, the GUI can be constructed to display a Windows®-based format. (Windows is a registered trademark of Microsoft Corporation in the United States and other countries).
A Java virtual machine (JVM) is an abstract computing machine that is responsible for hardware and operating system independence. As with a real computing machine, the JVM has an instruction set and it manipulates various areas of memory at run time. A hallmark of the JVM is its small compiled code and its ability to protect users from malicious computer programs. The JVM is aware of a particular binary format and class file format without knowing the particulars of the programming language. The JVM can host a language so long as it can be expressed as a valid class file. Typically, a single JVM runs as a single process on a physical computer, workstation, etc. having one or more monitors.
Java GUIs that run on multiple monitors use a single event queue and processing thread for all of the displays on all of the monitors. Event handlers detect any action that a user takes while operating a GUI (each monitor provides a GUI). These actions include, but are not limited to, pressing a button, clicking a mouse, dragging or selecting a menu item, etc. Such actions will cause the JVM to handle (process) each singular event. As a result, no other event from the GUI in the MMW can be handled until processing of that single event is completed. Consequently, other parts of the GUI freeze while processing of the single event occurs.
The “freezing” of the GUI on MMW monitors in a system while an event handler is processing an event on a particular part of the GUI is a serious limitation presented by Java Swing for MMWs. To overcome this problem, spawning another thread to process potentially slow event handling code does not solve two large problems: namely, (1) all display updates must be done on the event queue thread, causing graphic intensive processes to still freeze all of the GUIs across all monitors; and (2) use of multiple threads cannot generally be applied to third party commercial-of-the-shelf (COTS) software products that may be integrated into the GUI. Developers usually have no knowledge of how COTS software is written.
In addition to the freezing of GUIs, another problem with Java Swing's single threaded nature is that GUIs cannot take advantage of multiple processors and therefore receive no performance enhancement if a multi-processor machine is used.
In MMW applications, the GUI is composed using many hierarchical containers, including the top level JFrame container which produces a display region that can occupy up to a single monitor's total display surface area, and further including 1 to N (N being an integer) embedded JPanels which produce display regions each sized and laid out such that they can fill the display region produced by the JFrame container. The container class and its subclasses are often referenced without distinction between the abstraction and the resulting display. Such will be the case herein. Consequently, for ease of description, the JFrame container and its subclasses will not always be distinguished from the display produced by the JFrame container. The hierarchy of the GUI is flexible enough to permit containers within containers. Defined by each JPanel, and displayed within the display region produced by a JPanel, are all of the display regions created by the supported widgets such as buttons, menus, pull-downs, scroll bars, etc., which create these physical manifestations on-screen by the same name. This hierarchy of containers and layouts along with complexity of managing them is made more difficult in the MMW system by the presence of multiple monitors.
Another requirement for MMW systems is the ability to dynamically change GUI displays. Evolving task requirements and rapid prototyping both require an easy to alter GUI layout despite the multiple display requirements of the MMW.
Changing the layout in a Java Swing GUI requires recompilation of the software that describes the GUI layout. In applications, particularly ones in which an operator changes function or those where he/she has to switch from monitoring data to modifying data, the GUI display must likewise change as a result of changes in the GUI software. To do so using Java Swing, this requires that the GUI code be recompiled.
A need exists to resolve the freezing and rigid GUI design problems that arise in MMW GUI systems. Until now, no adequate solution existed.
Applicable reference numerals have been carried forward.